The present invention relates to storage of data in databases, and in particular, to a dynamic interface for accessing information from a database.
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Databases comprising rows and columns are highly useful tools allowing users to manage complex relationships between different types of data. In general, a database is created in a lower level code such as structured query language (SQL), and stored on a server. A user (typically at a remote client) accesses this data through a data services engine running a higher level language that provides a high level of abstraction from the basic database level. One example of such a higher level language is the Advanced Business Application Programming (ABAP) language of SAP AG.
FIG. 1 is a block diagram illustrating a highly simplified process flow 100 of a user posing a request for information from a database. In a first step, a human user 102 designs an extraction dataflow 104 using the data services designer 106 of a data services client 107. Herein, the extraction dataflow designed by a user in the context of a SAP system, is referred to herein as the ABAP Dataflow. However, the present invention is not limited to a SAP system, and could relate to other higher level languages used to interact with databases created in lower level languages.
Design of the extraction dataflow comprises specifying: i) the Source object(s) 104a, ii) the extraction transformations 104b, and iii) the structure of the output data table 104c. The specific structure of the output table is also referred to herein as the schema.
In a second step, the particular extraction dataflow designed by the user, is saved in a computer readable storage medium 108 that is in communication with the data services engine. While in this particular drawing, the computer readable storage medium is shown as part of the data services client, this is not required and the computer readable storage medium could be accessed remotely by the data services client through a computer network.
In a third step, a higher level language report 110 is generated by the data services designer based upon the extraction dataflow specified by the user. In a fourth step, the higher level language report 110 is communicated from the data services client through a remote function call connection 112 to the database application server 114, where it is processed by processor 115 and stored in repository 116 for processing to return the database information desired by the user.
Specifically, the processor of the application server interrogates the database in the low level language, and returns information relevant to the higher level language report 110 and the extraction dataflow present therein. In the particular context of a SAP system, an ABAP executable program writes a result to SAP Application Server file system.
Conventionally, this information returned from the database may be communicated back to the user at the client as shown in FIG. 2. This figure shows a simplified block diagram of a method 200 of data extraction from a SAP system.
In a first step 201, the data services engine 204 accesses the ABAP dataflow specification from the computer-readable storage medium in which it was previously saved. The data services engine retrieves ABAP report name from ABAP dataflow specification, and submits an ABAP job to execute the ABAP report.
The ABAP dataflow establishes a remote function call connection 205 to the SAP application server 206 using the NetWeaver Remote Function Call (RFC) Library 208 of the Data Services Engine 204. A submit batch job for the ABAP report communicated from the data services engine to the SAP application server includes the following pieces of information:                Dataflow parameters        SAP Application Server Local Directory        Data file name.        
In a second step 202, the dialog work process 208 of the SAP Application server 206 receives the batch job request through the gateway 210. This batch job includes the ABAP report including the above information.
In a third step 203, the batch work process 212 causes the ABAP report to execute a query to extract data from the source object pursuant to the dataflow. An ABAP internal table is created to load data from the extractor source object.
For each iteration of a data packet, the ABAP report writes 205 to the local file of the directory of the SAP application server host file system 213 specified as parameter. The data is converted to character format in order to write to the local file. The ABAP report then exits after writing the data to the local file.
In a fourth step 207, the data services engine monitors the dispatcher of the application server to detect when the batch job has finished. According to this conventional approach, the Data Services engine remains idle for the period of time that the ABAP report writes data to the local file. The idleness of the Data Services engine is attributable to at least two possible reasons.
First, data will be in inconsistent state when ABAP report is writing data in batches to a specified local file. During this period, if the Data Services engine (in step 207) reads the data from the specified file and process, then the result will be inconsistent. Hence the Data Services engine waits for step 203 to be completed.
A second reason is that when step 207 writes data to an operating system (OS) file, it may have held write lock. For some operating systems, it may not be possible to read data.
In a fifth step 209, when Data Services engine detects that the ABAP report has finished its execution, it connects to SAP Application Server host 206 through an operating system call 214. In a sixth step 211, the Data Services engine transfers the data to its local directory using its host file system 216. Conventionally, this transfer of data may be accomplished using either a shared directory copy, a file transfer protocol (FTP), or a third-party file transfer software.
In a seventh step 217, the data services engine reads the data from its local file, and processes the data. The retrieved data may then be displayed to the user from the data services engine.
While effective, the conventional approach for reading data from the application server may raise certain issues. For example, the conventional approach to transferring information may create large files that occupy space in the file system of the host application server. Moreover, accessing this information stored locally at the application server may consume processing resources by incurring input/output from the disk, delaying processing performance.
Another issue is that a user must specify in advance, the local file of the application server to which data of the report is to be written. This requires the user have knowledge and familiarity of the file system of a host application server, which he or she may not possess.
Still another issue is that in conventional approaches, the ABAP report reads the data from the internal table and converts the data to character format before writing as a delimited record. In doing so, the designer identifies a particular character for the local file which is not part of the data, and which can be used as delimiter (column and row). Thus under conventional read approaches, in designing ABAP dataflow the designer needs to recognize possible characters that can be extracted as part of dataset. The designer comes up with special characters (as delimiters) which are not part of dataset in order to separate data into columns and records. This can be a difficult task where a user is unfamiliar with the file system (and characters used) of a remote host application server.
Security is another possible issue raised by this conventional approach for transferring data. In particular, owing to security reasons it may be impractical to open a FTP port or a shared directory between the client and server. The system host and the data services engine host may also be located in separate network areas.
The present disclosure addresses these and other issues with systems and methods for implementing a dynamic interface allowing an external system to read data from a database through a unique remote function call (RFC) session.